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Abstract 

An effort has been undertaken by the National Aeronautics and Space Administration (NASA) to 
develop an automated post-test, post-flight diagnostic system for rocket engines. This project is 
a cooperative effort involving engineers and scientists at NASA Lewis Research Center, NASA 
Marshall Space Flight Center, Aerojet TechSystems Propulsion Division, Rockwell International 
Corporation Rocketdyne Division, and Science Applications International Corporation. The 
automated system is designed to be generic and to automate the rocket engine data review process. 
A modular, distributed architecture with a generic software core was chosen to meet the design 
requirements. The diagnostic system is initially being applied to the Space Shuttle Main Engine 
data review process. The system modules currently under development are the session/message 
manager, and portions of the applications section, the component analysis section and the intelligent 
knowledge server. This paper presents an overview of a rocket engine data review process, the 
design requirements and guidelines, the architecture and modules, and the projected benefits of the 
automated diagnostic system. 

Introduction 


The safe and reliable operation of a rocket engine depends on the proper function of each individual 
component of the engine. To insure successful engine operation many engineers and technicians 
test, troubleshoot, and where possible monitor critical engine components during operation. A 
large engineering effort is spent analyzing post-test/post- flight sensor data to determine if test 
objectives were met and if any anomalous conditions, or failures were present. This data review 
process is very time consuming and labor intensive. The core of the data review process is done 
by visually reviewing the data, which is in the form of numerous graphs. Because this data review 
process is common to all liquid propulsion rocket engines, the ability to automate the functions 
performed by the engineers would benefit both current and future liquid propulsion rocket engines. 
Thus, a need was identified for an automated diagnostic system for liquid propulsion rocket 
engines. 1,2,3 This automated diagnostic system has two basic requirements. These are 1) the system 
be developed with a generic core of software that is not engine specific, and 2) the system must 
automate the data review process. 

An effort was recently initiated by the National Aeronautics and Space Administration (NASA) to 
develop a generic post-test/post-flight diagnostic system for liquid rocket engines. This project is 
a cooperative effort involving engineers and scientists at NASA Lewis Research Center (LeRC), 
NASA Marshall Space Flight Center (MSFC), Aerojet TechSystems Propulsion Division, Rockwell 
International Corporation Rocketdyne Division, and Science Applications International Corporation 
(SAIC). After reviewing several liquid rocket engine propulsion systems, the decision was made 
to use the Space Shuttle Main Engine (SSME) as the first application of the generic post-flight 
/post-test diagnostic system. The SSME was chosen for several factors: 1) The SSME has 
approximately 135 firings and data reviews per year, 2) There is an extensive database that has 
been collected over the last ten years, and 3) The engine is currently planned to operate over the 



next twenty years. 


Even though the first application of this system will be the SSME, the system is designed with a 
generic core of software that is non-engine specific. This generic core of software will handle the 
common data review functions and the software system handlers. The system will also include 
software which can be customized for a particular engine. The diagnostic system under 
development will initially filter the data so that only the most critical sensor information is 
highlighted and presented to the engineer. The system will also provide many automated features, 
such as, a plotting package, statistical routines, and frequently used engine and component models. 
These automated features will be designed for ease of use, and will allow the engineer to find the 
required analysis tools in one software package. In the future, more encompassing diagnostic 
techniques and prognostic capabilities will be added to the system, such as pattern recognition 
techniques, neural networks, and quantitative models. This will improve the current data review 
process, in that information as to the time for replacement of a component is based on need rather 
than scheduled maintenance. 

The near-term potential of a post-test/post-flight diagnostic system is to provide the engineer 
reviewing flight or test data with an expedient means of reducing and interpreting the large amount 
of sensor data. Also, by developing and using this diagnostic system, insight into the types of 
algorithms and processes beneficial to performing rocket engine diagnostics and prognostics will 
be developed. By providing a better understanding of the propulsion system and its components, 
and the automation necessary for the diagnostic analysis procedures, the groundwork for developing 
an in-flight, or real-time, diagnostic/prognostic system is being developed. 

This paper highlights the overall procedure used by the engineers to review SSME test and flight 
data, and presents the design guidelines and software architecture chosen for the automated 
diagnostic system, and the system modules required. 

Data Review Process 


After an engine has been flown or tested, the engineers spend a considerable amount of time 
determining if an engine component, subsystem, or system operated normally. The engineers that 
perform the data review process are organized into four major analysis groups. They are the 
performance/ systems, combustion devices, turbomachinery, and dynamics groups. Also, there are 
data preparation support groups that produce all the graphs the engineers require to perform the 
data review. Figure 1 illustrates the amount of time spent by each engineering group to perform 
a normal data review. A normal data review is one where there are no anomalies, or where the 
anomaly can be easily resolved. As can be seen in Figure 1, the total amount time to review a 
normal firing is sixty-nine man hours. Since the results of the data review are required before any 
additional test can be conducted, this imposes a time constraint of twenty-four hours on the 
engineers. If the anomaly cannot be easily resolved the time for the data review increases by a 
minimum of twenty man hours. 4 

Figure 2 shows that the amount of time required to completely review a flight engine is sixty-four 
man hours. As can be seen in this figure, the amount of time required for the 
performance/systems, turbomachinery, and dynamics groups to review the flight data is greater than 
that required for a test. This is attributed to the critical nature of the flight engines, as well as 
there are three engines required for flight. The remaining groups have either a decrease in review 
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time or the review time remained constant. This is due to the decrease in the amount of sensors 
on the flight engines. 4 

Figure 3 illustrates the large amount of time required to perform a data review for the Technology 
Test Bed Engines (TTBE). Since this is a new test bed at MSFC and has had only two data 
reviews to date, the amount of time required per engineering group for the data review are only 
estimates. Some of the groups cannot safely estimate the review man hours, and therefore the time 
per those groups, in this figure, is to be determined (TBD). As can be seen in Figure 3, the 
amount of time required to review this data is estimated at 260 man hours. This large increase in 
review time is mainly due to the increased amount of sensors on the engines. 4 

The elements and logical flow of the data review process are given in Figure 4. As can be seen 
in this figure, the engineer receives the data in the form of various graphs (Block A), validates the 
data to insure proper sensor/instrumentation operation (Block B), reviews the data for anomalous 
conditions (Block C), and forms conclusions (Block D) as to the operation of the rocket engine. 
The review of the data plots is an iterative procedure which involves comparing the current data 
to past data, highlighting anomalous signatures, formulating a hypothesis as to the cause of the 
anomaly, and proving the hypothesis. 

The successful completion of the review of the data plots, Block C in Figure 4, relies heavily on 
the extensive knowledge required by the engineer. As seen in Table 1, the engineer must know 
not only general engineering principles, but also specifics about the engine operation and design, 
and how to access information sources. Table 2 illustrates some of the information sources that 
the engineer must routinely access when reviewing flight or test data. In some cases, the engineer 
may need additional information when investigating an anomaly in the test data. For example, the 
engineer at NASA MSFC may contact an engineer at Stennis Space Center to determine if anything 
unusual was observed during the test. Also, in the case of an anomaly, the NASA MSFC engineers 
rely heavily on past experience to remember the appropriate test(s) that have had a similar anomaly. 
The engineer must then retrieve the appropriate sensor plots for comparison to the current test. 
Depending on which past test needs to be retrieved, the engineer may locate the required graphs 
from a computer or paper database. 1,2,5 

By using knowledge, experience, and various information sources, the engineer visually review 
each sensor plot and formulates conclusions about the rocket engine operation (Block D in Figure 
4). There are several typical conclusions the engineers make. These are: 
o The data indicates a nominal firing 
o The data indicates an instrumentation problem 

o The data indicates an anomaly which can be attributed to hardware specifics 
o The data indicates a normal system degradation 

o The data indicates an anomaly which can be attributed to a well known and 
identifiable cause 

o The data indicates an anomaly of unknown cause 
The last of these conclusions is the worst possible conclusion; it requires at least twenty additional 
man hours to the data review time, in resolving and assessing the criticality of the cause. 

The heavy reliance on knowledge of the engine system, past tests, and information access makes 
the data review process a labor-intensive and time-consuming task. In order to assist the engineers 
an automated diagnostic system is being developed. This automated system will rely upon both 
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procedural and knowledge based software techniques implemented using a modular architecture. 

Automated Diagnostic System Description 


Architecture 

Two basic requirements of the automated diagnostic system are: 1) That the system be generic, and 
2) That the system automate the data review process. In order to satisfy these requirements the 
system was designed using the following guidelines: 

o Modular design with emphasis on non-engine specific core modules 
o Capable of handling large amounts of data 

o Include the types of knowledge required by the data review engineer 
o Interface with a variety of information sources 
The architecture chosen to implement these design guidelines is illustrated in Figure 5. 

As seen in Figure 5, the major sections of the architecture are: the intelligent knowledge server 
(IKS) section, the support application section, the component analysis section, and the 
session/message management section. Each of these sections contain a number of modules. The 
session/message manager modules, along with some of the support applications and most of the IKS 
modules are the sections that form the generic core of the diagnostic system. This is illustrated in 
Figure 5 by the shaded areas. These modules provide the backbone of the diagnostics system and 
are being developed to be non-engine specific. The component section modules are those modules 
that concentrate on individual engine component interrelations and mechanics. These four major 
sections of the automated diagnostic system, along with their associated modules, and software and 
hardware specifications are described in detail below. 

Intelligent Knowledge Server Section 

This section provides a function that is basic to the data handling of the diagnostic system. It 
handles large amounts of data and performs the "intelligent" access to the required information 
sources. The tasks involved include: maintenance of local database information, providing multi- 
database management, providing high-level math and property queries, performing data retrieval, 
presenting data in standard format, performing sensor or data validation and reconstruction, 
highlighting numerical points of interest, providing user or system customized tables, and providing 
knowledge about the previous tests with a similar anomaly. Most of the functions of this module 
involve the data and its retrieval, but conclusions and diagnosis, along with system reports also are 
included. The advantages of structuring the database in this format is to permit the source data to 
be located at various computer sites. From an implementation standpoint the commercial relational 
database INGRES provides several of the above envisioned tasks. 

An important module of the IKS section is the sensor validation and reconstruction module. The 
purpose of this module is to review the sensor data and to verify the proper operation of the sensor 
at the time of measurement. If the sensor was not operating properly, then the system would 
provide a reconstructed value for the system to use in the engine diagnostic process. The 
reconstructed values and the validation are to be provided to the system by means of a database 
table. An initial study into the best methods to use for validation and reconstruction showed that 
empirical based models were most successful in validating and reconstructing a sensor signal. The 
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constructed models are used to predict the expected sensor value. The predicted and the actual 
sensor values are then compared. If the difference is greater than a threshold, the system would 
determine that a sensor problem was probable, and provide a reconstructed value. 6 

A pplications Section 

The engineers that perform the data review require many different computer tools to perform their 
assessment of the engine. Each of the major tools will be implemented as a module. Two of these 
modules specialize in assisting and automating the data review process. These include the tools that 
locate, extract, analyze and present the data in a useful format. One tool that is currently being 
implemented is a CAE tool. This tool is being implemented as a module using PV-WAVE and will 
provide plotting, statistical analysis, and signal processing capabilities. Another tool is feature 
extraction. The feature extraction module is being written to extract characteristic and trend 
information from the data. It will produce a features table that will include data characteristics that 
engineers utilize in interpreting the data. 

Other application modules that will be included in the system are the startup analysis, mainstage 
analysis, shutdown analysis, two sigma exception analysis, SSME component and system models, 
and briefing preparation module. The startup, mainstage, shutdown and two sigma analysis are 
application modules required by the component analysis modules. They will provide core analysis 
routines that implement standard analysis procedures used during a particular engine phase, and 
provide a map of the engine during normal operation. The component and system models are 
existing models currently used during the data review process. The requirements of this 
implementation is to provide all of the necessary protocols to the model programs. This ability to 
integrate currently used models and programs within the automated diagnostic system provides the 
engineer with all the required data review tools in one software analysis package. The briefing 
preparation module will be capable of preparing the text, plots and graphs necessary for the data 
review presentations. 

Component Analysis Section 

There are four major engine-specific technical modules in this section used to analyze the SSME 
propulsion system. These include the performance analysis module, the combustion devices 
module, the turbomachinery module, and the dynamic data module. Each of these technical 
modules will be developed using the expert system shell NEXPERT, in forward chaining mode, 
for the knowledge-bases and procedural code. The primary function of these modules is to review 
the data characteristics and assess the condition of a engine component, sub-component or engine 
system. The modules must interact with other technical modules as well as with core system 
modules. Also, each of these modules contains sub-modules to perform specialized analysis 
functions. For example, the turbomachinery module contains four sub-modules. These are: the 
high pressure oxidizer turbopump, the low pressure oxidizer turbopump, the high pressure fuel 
turbopump, and the low pressure fuel turbopump sub-modules. The first technical sub-module 
being developed is the high pressure oxidizer turbopump sub-module. SAIC is scheduled to deliver 
this sub-module to NASA for evaluation in 1992. 

Session/Message Management Section 

The session/message manager section is comprised of three modules: the message manager module, 
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the session manager module, and the audit module. The session and message manager modules are 
embedded on top of UNIX and TCP/IP to form a software backplane that allows the diagnostic 
system modules to function as an integrated system. 

The message manager module determines the appropriate destination of the action required by the 
system and then sends the information using the appropriate function. Using the message manager 
to handle the logical-to-physical mapping allows the modules to communicate at a logical level. 
The message manager sends information either to a particular process, or to a blackboard, where 
the information may be received by whatever process requires it. 

The blackboard acts as a posting location for information. A central blackboard is used for the 
overall diagnostic system, and individual blackboards are used by each component analysis module. 
Blackboards are occupied by probes. Probes are pattern matching mechanisms that can look for 
messages, conclusions or other needed information, and send messages back to their owners when 
the pattern is matched. The blackboards will be implemented by either an INGRES file, or as part 
of the expert system’s working memory. NEXPERT currently provides this function, where the 
blackboard is constructed of facts, and rules function as the probes. 

The session manager module tracks the overall system. It provides information as to the current 
state of the analysis. It controls the starting and stopping of the diagnostic system, and also allows 
for the re-start of a particular session without loss of previous results. 

To ensure that the data analysis process is complete and correctly implemented, an audit trail 
module is required. The audit trail provides the information as to which data was examined, which 
events occurred, which hypotheses were considered, which modules and applications were ran, and 
what conclusions were made. The audit trail module works with the session manager and 
NEXPERT, and consolidates and reports the audit trails produced by the various processes of the 
diagnostic system. 

The session/message manager section is currently being implemented by SAIC. It is scheduled to 
be completed and delivered to NASA for evaluation in 1992. 

Software and Hardware 

The initial hardware chosen to host the automated post-test/post-flight diagnostic system is Sun 4 
workstation based. Even though these workstations have been selected, any UNIX platform with 
similar performance and software support would be sufficient. The software required for the 
diagnostic system includes X windows, INGRES relational database, NEXPERT inference engine 
and expert system shell, DAT A VIEWS with MOTIF user interface, PV-WAVE Computer-Aided- 
Engineering (CAE) system, and procedural code written in C. 


Concluding Remarks 

The two basic requirements of the automated diagnostic system being developed are: 

1) The system must be generic. 

2) The system must automate the data review process used in rocket engines. 

The first requirement allows the system to be used on a variety of current and future rocket 
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engines. The second requirement relieves the labor-intensive and time-consuming data review 
process. 

To satisfy the basic requirements, a set of design guidelines were identified and used in designing 
the automated system. These guidelines are: 

1) Modular design with emphasis on non-engine specific core modules 

2) Capable of handling large amounts of data 

3) Include the types of knowledge required by the data review engineer 

4) Interface with several information sources 

The architecture chosen for the diagnostic system meets these guidelines by employing a distributed 
and modular architecture that is both procedural and knowledge-based. Because the diagnostic 
system is designed to be distributed and modular, any future changes to the current SSME, as well 
as applications to future engines will result in procedural and uncomplicated modifications to the 
automated diagnostic system. 

A variety of benefits can be realized by implementing a rocket engine diagnostic system. A near- 
term benefit of developing this diagnostic system is to provide engineers with a tool that will allow 
for faster and easier assessment of a rocket engine system. Also, by thoroughly understanding the 
data review process, insight into future algorithms and diagnostic routines that would improve the 
procedures, as well as provide a better understanding of liquid rocket engines, can be achieved. 
In addition, development of a post-test/post-flight diagnostic system represents the first major step 
towards developing a real-time, in-flight diagnostic/prognostic system. A significant additional 
benefit of developing this system is the exchange of expertise and knowledge between NASA Lewis 
Research Center, NASA Marshall Space Flight Center, Rocketdyne, Aerojet, and Science 
Applications International Corporation. 

The post-test/post-flight automated diagnostic system is scheduled to be released for evaluation, 
with the majority of the system core modules and the SSME high pressure oxidizer turbopump sub- 
module, in 1992. Additional modular implementations and refinements are planned over the next 
several years. 


Disclaimer 


Trade names or manufacturer’s names are used in this report for identification purposes only. This 
usage does not constitute an official endorsement either expressed or implied, by the National 
Aeronautics and Space Administration. 
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RANGE OF KNOWLEDGE REQUIRED BY ENGINEER 

0 

Location of data, form of data, software being used for data display 

0 

Relevant historical data needed: parameters, firings, portion of firine(s) 

0 

How to evaluate data for sensor failures 

0 

How to operate modeling, data reduction, and plotting programs 

0 

How to manipulate data into relevant forms 

0 

Detailed understanding of SSME system and components, and 
manufacturing operations 

0 

Recognition of specific data anomalies and profiles 

0 

Heuristics for dealing with new anomolies 

0 

Understanding of how to evaluate and conduct a data review 

0 

Understanding of basic engineering and scientific principles 


TABLE 1: The range of knowledge required of the data review engineer and the post- 
test/post-flight diagnostic system 


MAJOR SOURCES OF INFORMATION 

0 

CADS and facility data files 

0 

Dynamics data file 

0 

Test objectives 

0 

Hardware inspection data 

0 

Statistical databases of hot-fire data 

0 

Anomalous database 

0 

Documents on how failures propagate and effect the system 

0 

Part tracking information 

0 

Build information and firing times per part 


TABLE 2: Major sources of information required by the engineer during the SSME data 

review process 
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FIGURE 1: Man hours per engineering group for a normal stennis test . 
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FIGURE 2: Man hours per engineering group for flight data 
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4 Dynamics Group 
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6 Total Man Hours 


FIGURE 3: Man hours per engineering group for a normal TTBE test . 

For groups with TBD, the data review time required cannot be reasonably estimated. 
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FIGURE 4: Elements and logical flow diagram of the data review process. 



FIGURE 5: Architecture For Post-Test/Post-Flight Diagnostic SystemCZD engine specfic 
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